Jump to content
  • Advertisement


The search index is currently processing. Leaderboard results may not be complete.

Popular Content

Showing content with the highest reputation on 08/31/19 in all areas

  1. 1 point
    Do you have a zip just with the game exe + required files? I'm not a fan of using installers for such games.
  2. 1 point
    And It's you again! Well, it's Saturday ... So it's time to publish a new blog post! This week has been full of small, subtle changes. Although no significant changes have been made, last week was a very busy one nevertheless! Loading phases First, let's start with arguably the most obvious change of them all. I decided to split the level generation into descriptive steps. This way, the player stays informed throughout the level generation process. Each time the game completes a step a GUI element gets updated. You can also specify a completion percentage. Some games (The Sims in particular) use this to increase the immersion in the game. So I decided to follow suit and gave each step a very Vaporwave description. And here's how it looks: Minor Updates Big UI refactor Changed the UI colours. Now each element got its own colour scheme. Refactored how most UI elements updates their colours: There are three types of update events: Atlas Updates, Window Updates and Container Updates. Elements that update themselves with atlas updates events waits until the current level index changes, after which colour updates happen. Elements that update themselves on window updates will instead wait until the window factory colours changes. Those elements can then fetch the standard window background colour as well as their standard header bar colour. Finally, elements that update themselves with a container update will wait until an abstract element (named "Container") changes its foreground and background colours. Refactored how texts in windows change their colours by using Container Updates events Refactored how windows change their colours By using Window Updates event Refactored how buttons change their colours by using Atlas Updates events Refactored a whole bunch of UI modifying classes so that they instead extends actual UI classes. This means that there's a bunch of new custom editors everywhere. This includes localized text, localized buttons, atlas tinted buttons, tabs, an much much more. This means that there's a bunch of pointless Animators components to remove. Thus less component to update thus better performance. Refactored how tabs works The actual tab itself now extends the Unity's Toggle class TabGroups now also extends the ToggleGroup class in the same manner Much like Unity's base Toggle, the relationship between Tabs and TabGroups are now described in the Tab class instead of the TabGroup one. There's a new TabContent class that deals with transitioning between tab states and whatnot. Most of these new Tab classes also get updated with Container Updates events. Renamed most UI elements to use standardized names: Every UI elements start with Vapor and end with Component. Refactored how Notifications works Now, most notification inherits form each other, thus less duplicate code. Changed how the Notification Queue works Now some notifications are marked unique. If another unique notification is about to be emitted we instead refresh the existing one with a little wobble. This way we can greatly reduce the amount of notification in the queue. Refactored how Notification Emmiter works so that they work with the new system Tweaked notifications priorities a bit. Refactored how Tooltip works Refactored how hoverable components work Fixed a bug where the wrong CurrentCulture was being used A bunch of other miscellaneous refactors and optimizations Next Week I'm not entirely finished the UI refactoring. Thus, finishing it will be my priority for next week. After all this, I want to focus on the enemies and, above all, the bosses. And then comes your usual suspects. But most importantly, I really want to focus on optimizing the game. I plan to have some kind of demo presentable very soon. I'm really trying my best to profile the game and identify weak points to which optimizing is critical. It takes time to get through all this data, but I'm confident I can do it.
  3. 1 point
    As of last night, I managed to complete everything I wanted for the basic game. The menu system is in place, all the game options are working, there's a full screen option, and I worked through some minor issues that I wanted to address. Full source code, and the 1.1 release, are available on my GitHub account. That puts me on track to start "phase 2", where I'll be working on a story mode with level progression. I think I have some neat-o ideas: Different types of fruits / veggies that have different effects on the snake. Each level will have its own design (ie. not just a rectangular playing area) and new types of barriers. A fun / silly story line where Adam has trapped the snake (you!) in his maze, to get revenge for tricking Eve into eating from the tree of knowledge of good and evil. I don't want to call them "cutscenes" really, but there will be some voiced scenes between each level as Adam throws increasingly difficult dangers into the mix. Here are some notes that might be of interest: While I used Photoshop to create the images used for the icon, there's a rather nice free Icon editor out there called Greenfish Icon Editor Pro. This is what I used to combine the various icon sizes, and export as the *.ico file. I wanted to create a setup / installer program for the game. I used Inno Setup for this. I was hoping this would automatically solve the issue of Windows security blocking the program from running by default. It looks like I'll need to investigate a "signing tool" to achieve this. For now, Windows 10 users have to manually unblock the program if they want to run it. One of the issues I tackled was related to the rendering of the grass and shrubs that make up the playing field. Originally, this was done using individual draw calls for every single tile. When I pulled the grass and shrub textures out into their own separate *.png files, and turned on texture repeating, this allowed me to render the entire grass with one draw call; and the shrub barriers with four draw calls. This was a significant performance improvement, shaving off about 3 milliseconds per rendering frame. Given that you only have 16.67 milliseconds to get everything done in one frame, that's pretty huge!
  4. 1 point
    It's been a while since my last developer journal. Mainly because I've been doing lots of things besides development. I've been playing lots of video games: Borderlands 2, Battletech, Master of Orion 2, and Blood Bowl 2. I've been doing lots of Blood Bowl and Twilight Imperium stuff including writing after action reports, twitch streams, and podcasts. I've also been completing some home improvement projects, learning German, working out, and just working. In short, I haven't made Car Wars a priority and so it doesn't get any of my time. Even though I've been productive in other "useful" things, my goof-off time hasn't really been a conscious decision and so I feel a little bit down from slacking off. This is something I've talked about in previous journal posts. It's okay to goof off so long as you prompt yourself, "Hey self. Instead of playing Blood Bowl, I could be working on my side project... Am I cool with goofing off and messing around instead of making progress?" If you ask yourself that and the answer is yes, goof off with a clear conscious. Otherwise you'll binge several hours of a video game and before you know it, that's one more day without any progress. Anyway, I actually HAVE made some progress. It's just not as much as I'd like. Most of this was working when I posted the last Car Wars journal. I worked out a few design decisions and fixed a few bugs. I also spent quite a bit of time cleaning up my object pooler, commenting the heck out of it and making the code asset worthy. I still need to do a few things like record a demo video, and create some store page assets for it before I can publish it on the Unity asset store, so expect that in a week or two. Here's a video for what I have so far: I have no skills in modelling, animating, or basically anything creative. So I franken-bashed a bunch of free assets together including different animations, a model, and making my own animation controller. I think it looks pretty cool for the prototype stage. I create the move order ghosts by instantiating a copy of the pedestrian through my object pooler, and make them translucent by turning the alpha of the materials down. To get the highlight effect, I just change the material color to yellow. // A couple of cached references to the renderers protected MeshRenderer tokenMeshRenderer = null; public MeshRenderer TokenMeshRenderer { get { if (tokenMeshRenderer == null) tokenMeshRenderer = GetComponentInChildren<MeshRenderer>(); return tokenMeshRenderer; } } protected SkinnedMeshRenderer modelMeshRenderer = null; public SkinnedMeshRenderer ModelMeshRenderer { get { if (modelMeshRenderer == null) modelMeshRenderer = GetComponentInChildren<SkinnedMeshRenderer>(); return modelMeshRenderer; } } private void SetTransparency(float transparency) { Color color = TokenMeshRenderer.material.color; color.a = transparency; TokenMeshRenderer.material.color = color; color = ModelMeshRenderer.material.color; color.a = transparency; ModelMeshRenderer.material.color = color; } public void SetColor(Color newColor) { Color color = TokenMeshRenderer.material.color; newColor.a = color.a; TokenMeshRenderer.material.color = newColor; color = ModelMeshRenderer.material.color; ModelMeshRenderer.material.color = newColor; } So now I have the very basics of turn-based mechanics worked out. I was lost in the weeds for a few days as I thought about all the different possibilities of how to tackle this problem. Do I let everyone plan everything and then execute in the correct sequence? What about collisions? How about allowing units to plan future phases out? What about keeping information from the other player hidden. How about when two cars are moving really fast and they're nearby each other? Should I present a timeline and allow the user to scrub through it for their planned movement and their opponent's approximated movement? ... and so on. Eventually I came to the conclusion that I need to just pick a direction and go. So I decided on something a bit simpler for now. Units will move in initiative order, and complete their movement for the phase before the next unit is allowed to go. This keeps the problem space much simpler and lets me work the kinks out of a turn-based mechanics system. As I code this simpler version, I'll try to make design decisions that consider some of the other problems I identified. Hopefully, that will make future refactors and features easier. Tips from your Uncle Eck If you don't make your game dev project a priority, then you won't make any progress on it. When you get overwhelmed by a complex design, take a step back and try to focus on a subset of the problem. Then expand on that as more of the problem gets solved. A decent solution now is far better than a perfect solution that never happens. Charity Fund Raising I'm helping raise money through Extra Life which is a charity that helps sick kids. Give a little something if you can. And share the links below if you have time. Thanks! My Extra Life page - https://www.extra-life.org/index.cfm?fuseaction=donorDrive.participant&participantID=367649 Twitter Post for sharing Facebook Post for sharing Notice/Disclaimer Car Wars is a registered trademark of Steve Jackson Games, and the Car Wars logo is copyrighted by Steve Jackson Games. All rights are reserved by SJ Games. This logo is used here in accordance with the SJ Games online policy. Computer Games based on SJ properties are prohibited so I'll never be able to release this project to the public (not even for free). It's just a fun personal project for myself and the most I'll be able to share is my experiences while working on it. In my pipe dream I'll get this into a cool enough state that SJ Games contacts me to publish the game. But what's more likely is a cease and desist letter. We'll just have to see how things go. Here's hoping. If you're interested in legit Car Wars products, I recommend Warehouse 23: http://www.warehouse23.com/products/car-wars-deluxe-edition
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!